In the related art, the Open Mobile Alliance Device Management (OMA DM for short) services are value-added services of mobile data based on related standards of OMA information Synchronization Mark up Language (SyncML for short) DM, which help operators achieve the capability of remotely managing mobile terminals through a wireless manner. A Device Management (DM for short) Client operating in a mobile phone is required to perform interactions with a server as specified in a protocol, to fulfill SyncML DM functions, wherein such functions include the device information management, the gathering and matching of parameters, the terminal software/firmware upgrade and etc.
The OMA DM protocol is an application protocol belonging to the OMA SynML protocol. In the OMA DM protocol, sessions complete various device management functions by means of sending various commands and acquiring terminal responses. The commands supported by the OMA DM protocol include many commands such as Get, Add, Replace, Exec (execute), Delete, and etc., and such supported commands are subsets of the OMA SyncML protocol.
As for each command, a series of status values are defined in the OMA DM protocol, so as to define definitely execution results of the commands in the sessions. The status values of the commands are defined in the protocol document named “OMA-TS-DM_RepPro-V1—2-20070209-A.pdf”. FIG. 1 is a schematic diagram of definitions of return values of a Get command of an OMA SyncML DM protocol terminal in the related art. As illustrated in FIG. 1, in the OMA SyncML DM protocol, the return values defined for the Get command comprise twelve values, including 200 (the command being executed successfully, OK), 215 (the command being not executed, Not Executed), 401 (Unauthorized), 404 (Not Found), 405 (the command being not allowed to execute, Command Not Allowed) and etc. These status values define definitely most results possibly occurring during an execution process of the Get command, for example, command being executed successfully, nodes being not found, being unauthorized, no authentification, operation being not supported, command being failed, Uniform Resource Identifier (URI for short) being too long, and etc.
In practical application, there may be a process manner in which an execution result of the Get command in the protocol has not been defined definitely, namely, performing acquirement operation on plural nodes (URI) through plural Items in the same Get command. Since the protocol has not definitely prescribed the process manner of the above mentioned case, it can be dealt with according to the following manners when it occurs in practical application.
1. If all URIs are acquired successfully, the status code 200 is returned for indicating success, and each acquired value is listed in a Result tag.
2. If the acquirement of URIs of one or more Items fails, the Get command returns “failure”, wherein the failure status code is the same as the failed URI. Furthermore, there is no Result tag to feed back the part of the nodes which are acquired successfully.
Hereinafter, the above process manners will be described by examples. In this example, synchronic packet header information is not listed completely, which however does not affect the explanation of the problem in the example. As illustrated in the following, a server sends a Get command containing plural Items in a certain phase after a session begins.
<SyncML><SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>8155</SessionID> <MsgID>1</MsgID>  ......omitted</SyncHdr><SyncBody> <Get>  <CmdID>1</CmdID>  <Item>   <Target>   <LocURI>./DevInfo/Lang</LocURI>   </Target></Item>  <Item>   <Target>   <LocURI>./DevInfo/Man</LocURI>   </Target></Item><Item>   <Target>   <LocURI>./DMAcc/AppAuth/Client/AAuthSecret</LocURI>   </Target>  </Item> </Get> <Final /></SyncBody></SyncML>
All the URIs that the above Get command intends to acquire are standard nodes specified in the DM protocol. In a Client, there is no authorization to acquire nodes specified in some Items. For example, as illustrated in FIG. 2, as for the /DMAcc/AppAuth/Client/AauthSecret node which is the password fields of authentication data, a server has only Replace authority rather than Get authority, that is to say, the case that some Items among plural Items are not authorized to acquire exists.
After receiving the above mentioned Get command, the Client executes an acquirement operation, and the execution fails in the third Item resulting from no authority, and the whole Get command returns a command 425 (No Authority, operation being refused). It should be noted that the realization of different Clients are different, so that other statuses indicating errors (such as 405) can also be returned. As shown in the following:
<SyncML xmlns=“SYNCML: SYNCML1.2”><SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>8155</SessionID> <MsgID>1</MsgID>......omitted</SyncHdr><SyncBody><Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef> <CmdRef>1</CmdRef> <Cmd>Get</Cmd> <Data>405</Data></Status> <Final /> </SyncBody></SyncML>
As mentioned above, the server is required to acquire information of three nodes, and actually the terminal has already acquired the information of two nodes thereof, but the acquirement of the third node fails. In the case that the acquirement of the information of most nodes is successful, the server only receives the indication indicating the execution of the Get command fails, and thus maximum amount of information has not been acquired. Such process wastes the process capability of the Client, and meanwhile also wastes network resources. Furthermore, if the server has no appropriate retry strategy (e.g. dividing the Get command to separately acquire), the required information can not be acquired comprehensively.